Feeble attempts at grokking the incomprehensible.
Having covered deployment jargon in Part 1 and approaches to deployment in Part 2, let us now consider what are the different types options for scripting deployments. This is one post where I will be taking specific examples as illustrations.
This is the simplest form of automation. The pre-supposition is that you have a well known number of boxes with a well understood operating system. The networking for these boxes has already been done. What you are really changing is the software running on these boxes; for example, in a unix box, you will ssh in and run shell scripts and in a windows box, you will enable winrm and run powershell scripts remotely. If the deployment fails (as they eventually start becoming fragile), you will likely have to log in to the particular machine, check to see what failed and then resume the deployment.
The concept needs some explaining, though there are several widely used examples of this type of deployment. All machines on which the deployment needs to occur have a client installed, which poll a server - the server issues deployment commands - which get executed on the clients. The results as reported by the clients, get aggregated and are available for your perusal. From the deploying engineer's point of view, the deployment steps look like:
The most common examples of this type of deployments are chef and puppet.
Traditionally, software engineers have taken a simplistic view of deployments which consisted of a shell script or an MSI executing a series of sequential steps. The steps list exactly what needs to be done and how to do it. Such a style of deployment is labeled imperative. Every time you write a script that asks for a directory to be created, files to be copied, permissions to be granted, services to be configured, databases to be created, tables to have rows inserted etc. you are using the imperative style of deployment.
This is in constrast with declarative deployments where you specify the final desired state and hand your code over to a managing entity who then moves your code through a series of steps ending in the desired outcome for you. Declarative deployments rely on this managing entity and a specification language for this entity. Declarative deployments are gradually becoming the industry standard. The pros for these are
The biggest con really is that you will have to pick a specific implementation and you will get locked in to your choice, because your investment in using the plugins etc is unlikely to port easily into a differet management entity. There are numerous choices in this regard. You can pick up Chef or Puppet mentioned before. On Windows, on a per server basis, you can choose PowerShell Desired State Configuration. There are PAAS providers like Heroku, Google app engine or Microsoft Azure which also provide this type of deployments.
Unless you are committed to owning hardware in some datacenters, most people have looked at using VMs for their service. If you are using some PAAS solution, then VM allocation is solved by the hoster for you automatically. You have numerous options when it comes to selecting IAAS providers like AWS, Rackspace, Linode, DigitalOcean or Azure. Each of them provide their own ways of VM allocation and you have to learn the quirks of each before you can use it. If however, you want the peace of mind of spanning IAAS providers (for better uptime), then you might want to take a look at Vagrant, which can help allocate VMs across multiple providers and also install chef/puppet clients for you.